【Aurora】とあるWebサイトのDBをAmazon Auroraに移行してみた

【Aurora】とあるWebサイトのDBをAmazon Auroraに移行してみた

Clock Icon2015.10.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWSチームのすずきです。 今月(2015年10月)よりAWS東京リージョンで利用可能となった、RDS for Amazon Aurora。 とあるサイトのCMS(WordPress)のバックエンドDBとして稼働していたRDS(mysql)を移行し、 Amazon Auroraの性能の一端を確認できる機会がありましたので、紹介させて頂きます。

概要

  • RDSのスナップショットより、スナップショットの移行(migrate)を実施しました。
  • ElasticBeanstalkの機能(クローン、DNSスイッチ)を利用して、RDS(Aurora)参照環境の構築と切替を実施しました。
  • DBの最終同期として、mysqldumpコマンドによるエクスポート、インポートを行いました。

システム概要図

migrate-wp-mysql2aurora-07

移行手順

スナップショットの復元

  • AWSコンソール、RDSのスナップショット画面より復元対象とするRDS(MySQL)のスナップショットを選択し、「スナップショットの移行」を実施します。
  • 今回、日時バックアップで取得済みのスナップショットを指定しました。

migrate-wp-mysql2aurora-01

  • Amazon Auroraのインスタンスクラスは「db.r3.large」、VPC設定は既存RDS(MySQL)を踏襲した指定を行いました。

migrate-wp-mysql2aurora-02

  • ステータス「作成中」となります。
  • リストア開始などの進捗はRDSイベントとして表示されませんが、今回の300MBほどの容量のDBでは、30分ほどでDBが利用可能となりました。

migrate-wp-mysql2aurora-03

ElasticBeans環境

  • ebのクローン機能を利用し、検証用のEC2、ELBを起動しました。
  • ebの環境変数設定で、接続先DBのエンドポイントをRDS(MySQL)→RDS(Aurora)に変更しました。

性能比較

NewRelic

  • NewRelicのAPM(PHP)監視を利用し、Top database operations by time consumed、Databese response time値の比較を行いました。

RDS(MySQL)

  • 移行前
  • スペック:db.m3.medium、Multi-AZ、EBS(GP2)

migrate-wp-mysql2aurora-05

RDS (Aurora)

  • 移行後
  • スペック: db.r3.large、single

migrate-wp-mysql2aurora-04

Top database operations by time consumed

  • 数値は小さい(所要時間が短い)程、高性能
処理区分 RDS(mysql) RDS(Aurora)
最小値 40ms 18ms
最大値 110ms 35ms
中間値 50ms 25ms

Databese response time

  • 数値は小さい(所要時間が短い)程、高性能
処理区分 RDS(mysql) RDS(Aurora)
insert 30〜50ms 9ms
other 3ms 2ms
select 5ms 3ms
delete 25〜30ms 7ms
update 25〜30ms 6ms

インポート、エクスポート性能

  • mysqldumpコマンドでエクスポート、インポートの所要時間を比較
  • ダンプファイルの容量は約300MB
  • 所要時間は短いほど高性能

インポート

RDS(MySQL)
real 1m0.672s
user 0m1.820s
sys 0m0.064s
RDS(Aurora)
real 1m8.394s
user 0m1.672s
sys 0m0.224s

エクスポート

RDS(MySQL)
1回目
real 0m10.745s
user 0m1.648s
sys 0m0.088s
2回目
real 0m10.709s
user 0m1.680s
sys 0m0.088s
RDS(Aurora)
1回目
real 0m45.762s
user 0m1.452s
sys 0m0.172s
2回目
real 0m2.918s
user 0m1.400s
sys 0m0.044s
  • Auroraの1回目、より別データのインポート、エクスポートを数回繰り返した後に、測定した値です。
  • 3回目移行を続けて実施した場合、その性能は3秒前後で安定していました。

コスト比較

  • 東京リージョンのDBインスタンス費用のみを30日分で比較

RDS(MySQL) Multi-AZ

  • db.m3.medium : 172.8 $ ※移行前
  • db.m3.large : 345.6 $
  • db.r3.large : 410.4 $

RDS(Aurora)

  • db.r3.large (Single) : 252 $ ※移行後
  • db.r3.large (Multi-AZ) : 504 $

AuroraのストレージはAZ間で冗長化されている事。 また、シングルノードであっても、AZ障害時のフェイルオーバは通常15分以内で完了するとされている事から、 今回のCMS環境のAuroraはシングルノードで十分と判断し、月額費用は172.8$ → 252$に抑えました。

まとめ

今回のCMS環境ではRDSのMySQL→Auroraへの移行により、DB性能の大幅な向上が確認できました。

また、移行作業を通じて、RDS for Amazon Auroraには非常に強力なキャッシュ機能が存在している事が伺えました。 その性能特性などについては今後の課題として、より深く調査してみたいと思います。

今後、AWS上で一定規模以上のRDBMSを稼働させる場合、Amazon Auroraが費用対性能に 優れたDBとして利用できるケースが多くなると予想されます。 東京リージョンで利用可能となったAmazon Auroraの性能、是非お試しください。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.